[WIP] Dev issue #766 #847
[WIP] Dev issue #766 #847
Conversation
|
Hi @Garic152 , thanks for the PR. The segfault happens here in the The problem seems to be that the condition of the Here is the IR of the Her is the IR of the The loop condition here is evaluated to While the Looking at the documentation of the scf::WhileOp, I think this is a bug on our side, we cannot simply assume that the
I debugged the current code at We sadly don't have any tests besides To sum up, the segfault you are experiencing comes from a bug in the existing code concerning the special treatment of |
Work in progress PR for #766.
After some more debugging, I am unfortunately still facing segmentation fault issues due to the
test/api/cli/algorithms/components.daphnetest when using the following command:After adding the RowAggMaxOp, the test does work and gives the same
--explain property_inferenceoutput as the main branch.When adding the
SparsityRemainsIfAllInputOneOrZerotrait in theDaphneInferSparsityOpInterface.cppfile to both theewMinandewMaxoperation, the property inference pass does work, but the select_matrix_repr pass fails with a segmentation fault issue, which I included in this gist file.I compared the property inference pass output from both the main branch (right side) and #766 (left side) and found only one difference (the 2 outputs are included in the gist file as well):
Before going into the while loop, there is another cast operation in the main branch, which is not in included after adding the sparsitytrait for ewMin and ewMax. I unfortunately cannot come up with a reason why this is the case, but strongly think this might be the reason for the segmentation fault.
After further examining the while loop with all the previously mentioned sparsity traits added, I noticed that when not using a while loop (which i changed to loop 2 times) to calculate the result for
c, but rather repeating the contents twice manuallythe code executes without any problems, which further adds to the confusion of why not using a while loop, which should not change the codes logic, changes the outcome in terms of the passes.
I will continue to examine the behaviour of the code over the next few days and perhaps add the sparsity estimators one by one to see where errors might have occurred, but especially after the strange while loop behaviour I am starting to run out of ideas on how to properly fix this segfault problem.
Edit: After having executed the above mentioned cli test, I have actually come across another segfault error type once now, which I included at the end of the gist file. I am not sure if this is related to the changes in #766 or if it's maybe just hardware related, but wanted to mention it nonetheless.